home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / satellit / pacdoc / uo14info.txt < prev    next >
Text File  |  1994-08-24  |  41KB  |  1,019 lines
  1.  
  2. This file is a compliation of various bulletins about UO-14 operations.
  3.  
  4.  
  5. From      : g0k8ka
  6. To        : all
  7. Title     : Addressing Mail
  8. Keywords  : PG HEADERS ADDRESSES
  9. Uploader  : G0K8KA
  10. Uploaded  : Wed Jan 16 12:26:56 1991
  11. __________________________
  12.  
  13. BULLETINS - These are messages which would be of interest to many people
  14. on the satellite.  They should have "ALL" in their destination field.
  15. "ALL" must be the first thing in the destination, not preceeded by any
  16. spaces.  Additional information about the subject of the message should
  17. be put in keywords and/or the title field.
  18.  
  19. PRIVATE MAIL - This is a message to a specific station. That station's
  20. callsign must appear in the destination field of the file. The callsign
  21. must be complete, without any extra spaces or other characters in it. It
  22. may be preceeded or followed by other words.
  23.  
  24. The following destinations will show up as mail for G0K8KA:
  25.  
  26. g0k8ka
  27. G0K8KA
  28. G0K8KA@UOSAT3
  29. G0K8KA.UK.EU.EARTH
  30. NK6K+G0K8KA+N4HY
  31.  g0k8ka
  32.  
  33. The following destinations will not show up as mail for G0K8KA:
  34.  
  35. G0/K8KA
  36. gok8ka
  37. g0 k8ka
  38.  
  39. Notice that case does not matter.
  40.  
  41. Forther notes on addressing will be provided when necessary. We don't intend
  42. to force any particular addressing scheme on the network, but certain
  43. conventions must be adhered to.
  44.  
  45. JWW
  46.  
  47. From      : g0k8ka
  48. To        : all
  49. Title     : PG HINTS
  50. Keywords  : PG
  51. Uploader  : G0K8KA
  52. Uploaded  : Sat Feb 09 12:52:27 1991
  53. __________________________
  54. I am still working on complete documentation for the newest release
  55. of PG. In the mean time, if there are any questions, you can direct
  56. them to me here on UoSAT-3.
  57.  
  58. - If there is any chance that you will turn MALL ON, you should put
  59.   a line MALL OFF in your PG.TNC file. This keeps connected mode
  60.   packets from interfering with the detection of the BBSTAT beacons.
  61.  
  62. - The Serial I/O report at the end of the program should help us
  63.   diagnose some of the problems which end with "unexpected packet"
  64.   and the binary rubbish display. Missed interrupts are caused by
  65.   other interrupt-driven programs (i.e. TSRs keeping interrupts turned
  66.   off for too long). 4k Buffer overflows are caused when interrupts
  67.   are enabled (good) but PG is not allowed to run (bad).
  68.  
  69. - The new version has been built with Microsoft C 6.00a, rather than
  70.   5.1. I noticed here that the C6.00a video routines interacted strangely
  71.   with one of our VGA BIOSes. I was able to solve the problem on that
  72.   specific machine by setting MODE BW80 on the DOS command line. Why?
  73.   I don't know.
  74.  
  75.   If you have persistant problems which might be video problems, you
  76.   should set the environment variable MONO=ON. This will force PG to
  77.   work in monochrome mode, which should at least test different portions
  78.   of your BIOS!
  79.  
  80. - There has been one report of complete crash/burn with the new PG. I suspect
  81.   that the video drivers are involved in this, but I have no solution.
  82.   I'll try my best, but all I can do is test it here with our hardware and
  83.   then ship it! We use a DELL 316 (16 MHz SX) in the groundstation and I
  84.   use some no-name clone 386DX 20MHz for development. All of our TNCs are
  85.   PacCom Tiny-2 with TAPR V 1.1.7.  It works here!
  86.  
  87. 73, JWW
  88.  
  89.  
  90. From      : g0k8ka
  91. Title     : Headers, BIDs, and BBSs
  92. Keywords  : BID PBBS PFHADD PACSAT PROTOCOLS
  93. Uploader  : G0K8KA
  94. Uploaded  : Thu Jan 24 12:00:02 1991
  95. __________________________
  96. Please refer to PACSAT File Header Definition.
  97.  
  98. BBS MESSAGE TRANSFERS
  99.  
  100. When we designed the PACSAT Protocol Suite, we attempted to support
  101. all imaginable terrestrial bulletin board operations, without forcing
  102. any particular scheme of addressing or routing onto the terrestrial
  103. operators.  Nevertheless, it is important that terrestrial BBS
  104. operators use the PACSAT Protocols in an efficient manner which takes
  105. full advantage of available features.
  106.  
  107. The PACSAT Protocol Suite supports bulletin-board file transfers in
  108. two ways:
  109.  
  110. (1) a single BBS message can be transferred in a single PACSAT
  111. file,
  112.  
  113. (2) multiple BBS messages can be transferred as one PACSAT file.
  114.  
  115. For each of these methods, there is an appropriate PACSAT file type.
  116. File type 0x01 is for a single message, and file type 0x02 is for
  117. multiple messages. We expect that multiple messages will be
  118. transferred in the RLI/MBL standard export format. If other formats
  119. are to be used, further file types will be assigned.
  120.  
  121. The advantage of using a unique FILE_TYPE for such files is that
  122. groundstation software can use the PACSAT SELECT command to select
  123. only BBS-type messages, and ignore all others. This will be useful
  124. when PACSAT BBS gateway software is implemented.
  125.  
  126. Please use the proper FILE_TYPE when uploading BBS messages to
  127. PACSAT.
  128.  
  129. If you believe that additional file types are needed, contact NK6K or
  130. G0K8KA. (Eventually, this will be handled by AMSAT operations crew
  131. members, but for now the developers will keep a hand in the
  132. assignments.)
  133.  
  134. BULLETIN IDs
  135.  
  136. The use of BIDs is related to BBS traffic, but should not be
  137. restricted to BBS traffic.  I guess that every message to "ALL",
  138. which might be downloaded and inserted into the terrestrial BBS
  139. network, should have a BID. The BID should NOT be placed in the text;
  140. it should be in the PACSAT File Header, where an appropriate item id
  141. (0x21) has already be defined.
  142.  
  143. Correct assignment of BIDs is left to the terrestrial network gurus;
  144. I just want them put in the appropriate place.
  145.  
  146.  
  147. JWW
  148.  
  149.  
  150. From      : g0k8ka
  151. Title     : UO-14 Whole Orbit Data
  152. Keywords  : UO14 WOD TELEMETRY
  153. Uploader  : G0K8KA
  154. Uploaded  : Mon Jan 21 11:45:55 1991
  155. __________________________
  156.  
  157.                      UoSAT SPACECRAFT DATA SHEET
  158.  
  159.                         UNIVERSITY OF SURREY
  160.                       Guildford, Surrey GU2 5XH
  161.                  Tel: 0483-509143    FAX: 0483-34139
  162.  
  163.            WOD ON THE UOSAT-3 PACSAT COMMUNICATIONS EXPERIMENT
  164.  
  165. The PCE can conduct Whole Orbit Data surveys much like those supported by
  166. previous UoSAT onboard computers, but with some enhancements. The PCE
  167. Housekeeping Integration Task can sample up to 3 WOD surveys
  168. simultaneously, and the sample rate of a survey can be any value from 1
  169. second upward.
  170.  
  171. The PCE stores WOD and other information in an internal solid-state file
  172. store. WOD surveys are stored in binary files with Standard PACSAT File
  173. Headers (described in a separate document called PACSAT File Header
  174. Definition). As indicated in that document, the <file_type> in the header
  175. of a UoSAT-format WOD file is 3.
  176.  
  177. WOD files in the PCE file store are named using the following convention:
  178.  
  179. wdMMDDNN
  180.  
  181. wd - indicates that the file is a whole-orbit data file.
  182. MM - is replaced by a two digit month number, starting with 01 for January.
  183. DD - is replaced by a two digit day of the month.
  184. NN - is replaced by a two digit survey number, starting each day at 0.
  185.  
  186. For example, the first whole orbit data survey taken on the 3rd of February
  187. will be in file a file named "wd020300".
  188.  
  189. WOD files can be downloaded using the UoSAT-3 file server or received
  190. passively using the PACSAT Broadcast Protocol. These procedures are
  191. described in two documents: PACSAT Broadcast Protocol and PACSAT Protocol:
  192. File Transfer Level 0.
  193.  
  194. BINARY FILE FORMAT
  195.  
  196. Once a WOD file has been downloaded and its PACSAT file header removed, the
  197. file body contains a WOD survey in the standard binary format defined
  198. below.
  199.  
  200. (Data structures are described in a C-like syntax defined in the document
  201. PACSAT Data Specification Standards.)
  202.  
  203. All multi-byte values are stored least significant byte first.
  204.  
  205. 'long' is 4 bytes
  206. 'int'  is 2 bytes
  207. 'char' is 1 byte
  208.  
  209. WOD files begin with a WOD_HEADER structure.
  210.  
  211. WOD_HEADER {
  212.   unsigned long start_time;
  213.   unsigned long end_time;
  214.   int sample_period;
  215.   unsigned char number_of_channels;
  216. }
  217.  
  218. The header is followed by the channel numbers, each one stored as an
  219. unsigned char (e.g. a single byte).
  220.  
  221. <start_time> is the start time of the WOD survey, an unsigned 32-bit binary
  222. integer counting the number of seconds since Jan 1 1970.
  223.  
  224. <end_time> is the ending time of the WOD survey, time encoded as above.
  225.  
  226. <sample_period> is the number of seconds between samples in the survey.
  227.  
  228. <number_of_channels> is an 8-bit unsigned binary integer telling how many
  229. channels were in the survey.
  230.  
  231. The following <number_of_channels> bytes are the channel numbers
  232. themselves.
  233.  
  234. This header is followed by the data samples from the survey. Each data
  235. sample contains <number_of_channels> channel values. The channel values are
  236. stored as unsigned 16-bit integers. Within each sample the channel values
  237. are in the same order as specified in the WOD_HEADER. That is, if the wod
  238. header says that channels 12, 13 and 22 are being sampled, each sample in
  239. the file will be three 16-bit integer values, the first from channel 12,
  240. the second from channel 13 and the third from channel 22.
  241.  
  242. For example, here is the beginning of a survey taken on the UO-14
  243. simulator, where the actual telemetry values have been replaced by their
  244. channel numbers (e.g. reading telemetry channel 1 always returns 1).
  245.  
  246. The survey started at 0x26495e00, ended at 0x26495e78, was sampled every
  247. 0x0001 seconds, contained 0x04 channels and those channels were channels 01
  248. 02 03 and 04. The first two samples from the survey are then included.
  249.  
  250. 00 5E 49 26 78 5E 49 26 01 00 04 01 02 03 04 01
  251. 00 02 00 03 00 04 00 01 00 02 00 03 00 04 00
  252.  
  253.  
  254. From      : g0k8ka
  255. Title     : UO-14 Status
  256. Uploader  : G0K8KA
  257. Uploaded  : Tue Jan 22 14:30:15 1991
  258. __________________________
  259.  
  260. ADDRESSING MAIL
  261.  
  262. Mail for UoS should be addressed to "G0K8KA".
  263.  
  264. JWW
  265.  
  266. From      : g0k8ka
  267. To        : all
  268. Title     : Status Report
  269. Keywords  : UO3 FTL0 PB
  270. Uploader  : G0K8KA
  271. Uploaded  : Wed Apr 10 11:26:31 1991
  272. __________________________
  273. ** STATUS REPORT **
  274.  
  275. New features introduced during uploads (2/4, 3/4, 9/4, 10/4):
  276. BROADCAST PROTOCOL -
  277.  
  278. Now reflect callsign of requesting station in the "OK" packet. The Broadcast
  279. Protocol implementation is still far from complete, and is nearing the top of
  280. the To Do list.
  281.  
  282. FTL0 -
  283.  
  284. Changes to activity log files to allow more detailed analysis of throughput.
  285. Log entries now mark the beginning and end of each "transaction", and count
  286. the number of bytes transferred during the transaction.
  287.  
  288. Reception of an illegal FTL0 packet now causes immediate disconnect; the
  289. activity log will provide a reason for the disconnection. These errors are
  290. almost always an indication of data loss between your PC and TNC, look for the
  291. "BLOWOFF" indicator in the new alog display program output.  (New alogdisp
  292. will be posted ASAP.)
  293.  
  294. ERROR DETECTION AND CORRECTION -
  295.  
  296. The RAMDISK is now being error washed on a regular basis; this should
  297. eliminate the already vanishing possibility that you will receive a file
  298. corrupted by radiation induced single event upset. The error log file, now
  299. called "eltlog" should reflect accurately the single event upset rate in the
  300. entire 4 Mbytes of RAMDISK space. A new version of the elogdisp.c program will
  301. be forthcoming.
  302.  
  303. FURTHER UPLOADS -
  304.  
  305. I hope that I will be able to retain files during future uploads, but this
  306. depends on the nature of the "crash" or whatever brings the system down. I am
  307. going to implement a "file system consistancy checker" to run before I warm
  308. start the file system; this will detect and correct simple problems like lost
  309. clusters or chains. If no major problems are found by this test, a warm start
  310. will be used, and files will not be lost. If major problems are detected, I'll
  311. have to cold start.
  312.  
  313. Expect further uploads after I have time to work on the Broadcast Protocol, or
  314. when a fix comes through for the buffer loss problem which has slowly brought
  315. LUSAT and PACSAT to a halt.
  316.  
  317. 73, JWW
  318.  
  319. From      : g0k8ka
  320. To        : all
  321. Title     : Memory Efficiency
  322. Keywords  : UPLOADING LIFETIME
  323. Uploader  : G0K8KA
  324. Uploaded  : Mon May 13 18:57:00 1991
  325. __________________________
  326.  
  327. When you are uploading a file and get interrupted by LOS or for some
  328. other reason, please try to CONTINUE THE UPLOAD. Don't start a new upload
  329. of the same file.
  330.  
  331. If you abandon the partial upload and start fresh, you will leave behind
  332. a file fragment which takes up space in the file system and is no use to
  333. anyone. This is especially important for long files, where the fragment you
  334. leave behind can be the equivallent of several "normal" length messages.
  335. I just wanted to remind everyone that the partial files do sit around for a
  336. while (>7 days). Perhaps this time should be shorter?
  337.  
  338. I'm not trying to discourage anyone from sending long files. UO-14 is
  339. a good way to relay the big ones; that's what it's here for. I'm just
  340. trying to encourage efficient operating practice. Right now (13 May), we
  341. are using UO-14's memory almost to its full capacity, and big fragments
  342. can force early removal of many small messages.
  343.  
  344. The automatic removal algorithm tries to make sure that
  345. there is 500 kbytes of free disk space and 50 free directory entries.
  346. This automatic procedure has allowed us to have a hands-off maintainance
  347. system even without a "Kill" command.
  348.  
  349. JWW
  350.  
  351.  
  352. From      : g0k8ka
  353. To        : all
  354. Title     : Monitoring Activity
  355. Keywords  : alogdisp
  356. Uploader  : G0K8KA
  357. Uploaded  : Thu May 23 11:05:07 1991
  358. __________________________
  359. Please monitor your own station's operation and not any anomolies
  360. that you observe regularly. This is the only way that we software
  361. developers can track down bugs and decide on the merits of enhanced
  362. features.
  363.  
  364. If, for example, you attempt to download a message some 20 or more
  365. times, with the same undesirable consequences, please drop a message to
  366. the spacecraft software developer (G0K8KA) and the groundstation
  367. software developer (whoever that is).
  368.  
  369. Using the activity log display program, you can see what your station did
  370. on the previous day.
  371.  
  372. alogdisp al910522 pa3dvg
  373.  
  374. would list pa3dvg's activities on the 22 of April.  From the alog display
  375. you can begin to see if the satellite has a hard time hearing you or
  376. vice versa.
  377.  
  378. Thank you in advance for your input,
  379.  
  380. JWW
  381.  
  382. From      : g0k8ka
  383. To        : all
  384. Title     : alogdisp
  385. Uploader  : G0K8KA
  386.  
  387. Below are the results of some ALOG file analysis that I've been working on.
  388. For each day, I show the total number of seconds "session time" accumulated
  389. that day. Below, that time is broken down into 5 percentages.
  390.  
  391. Idle     - time when no command was being processed. This must be both a
  392.            legitimate reflection of idleness and an artifact of the way
  393.            that directories and selects are logged.
  394. Upload   - time spent between the receipt of the upload command by the
  395. satellite
  396.            and the completion of the final handshake.
  397. Down     - time between the receipt of the download command and the completion
  398.            of the final handshake.
  399. Dir      - Time between receiving dir command and sending last data packet.
  400.            (Note innaccuarcy here compared to download time.)
  401. Select   - Time between receiving select command and sending sel response.
  402.  
  403. If we ignore idle time for a moment, taking it as enevitable, then we see that
  404. downloads take the largest percentage of the satellite connected-mode activity,
  405. before and after the changes to the broadcast protocol.
  406.  
  407. (This data looks good as vertically stacked bar graphs, with a bar per day.
  408. The bars are equal length (100%) and you can visually trace any changes.)
  409.  
  410. JWW
  411.  
  412.  
  413.  DATE       910410    910411    910412    910413    910414    910415    910416
  414.  Total      3098.0    3753.0    3258.0    5561.0    4915.0    4213.0    5128.0
  415.  % Idle       44.9      36.9      33.6      39.9      36.9      33.1      42.2
  416.  % Upload     10.6       1.8      10.0       4.8       6.6        .9       2.0
  417.  % Downlo     37.2      46.4      40.0      38.7      42.8      51.6      39.9
  418.  % Direct      6.1      13.6      14.6      14.3      11.5      12.8      13.3
  419.  % Select      1.2       1.4       1.8       2.4       2.2       1.6       2.6
  420.  
  421. DATE      910417   910418   910419   910420   910421   910422   910423   910424
  422. Total     4543.0   4488.0   3832.0   7105.0   7449.0   5914.0   5837.0   7491.0
  423. % Idle      43.2     40.6     36.5     49.1     37.2     35.5     40.1     45.0
  424. % Upload     2.6      4.2      5.7      8.6      3.6      3.1     11.1      4.7
  425. % Downlo    38.5     32.2     37.6     23.6     42.3     42.6     25.1     25.6
  426. % Direct    13.9     20.1     16.7     16.0     14.1     15.1     19.0     20.5
  427. % Select     1.9      3.0      3.5      2.7      2.8      3.7      4.6      4.2
  428.  
  429.  DATE       910425    910426    910427    910428    910429    910430    910501
  430.  Total      7387.0    4124.0    5784.0    7353.0    6831.0    6583.0    7799.0
  431.  % Idle       43.3      35.0      39.3      38.4      37.2      31.0      33.1
  432.  % Upload      6.9       3.4       1.1       7.9       8.0      21.5       5.8
  433.  % Downlo     29.4      46.2      42.9      34.0      33.3      27.0      39.7
  434.  % Direct     16.5      12.7      13.0      15.7      17.7      16.3      17.8
  435.  % Select      4.0       2.7       3.7       3.9       3.8       4.2       3.5
  436.  
  437.  DATE       910502    910503    910504    910505    910506    910507    910508
  438.  Total      4953.0    5391.0    8378.0    8667.0    6830.0    5146.0    3887.0
  439.  % Idle       26.9      26.1      29.2      37.3      35.2      33.4      46.3
  440.  % Upload      1.8       3.2       8.3       8.8       9.4       5.5       2.4
  441.  % Downlo     56.4      60.1      43.2      35.3      33.8      44.3      24.7
  442.  % Direct     12.4       7.7      16.4      15.2      18.2      12.8      21.0
  443.  % Select      2.5       2.9       3.0       3.5       3.4       4.0       5.6
  444.  
  445.  
  446.  DATE       910509    910510    910511    910512    910513    910514    910515
  447.  Total      6722.0    7483.0    8826.0    7702.0    4921.0    6583.0    7047.0
  448.  % Idle       35.9      39.1      31.7      34.4      31.1      32.9      38.4
  449.  % Upload      7.0       5.0      21.7       5.6      12.4      13.7       8.3
  450.  % Downlo     38.1      34.0      24.4      38.7      38.6      34.3      28.0
  451.  % Direct     14.6      15.6      18.2      17.4      12.9      14.0      19.8
  452.  % Select      4.4       6.3       4.1       4.0       5.0       5.1       5.5
  453.  
  454.  DATE       910516    910517    910518    910519    910520    910521    910522
  455.  Total      5454.0    6015.0    9694.0    7155.0    9825.0    7181.0    6573.0
  456.  % Idle       33.2      38.3      38.6      31.8      49.6      48.5      32.6
  457.  % Upload      2.6       4.0       4.2       2.9       4.7       1.1      12.4
  458.  % Downlo     44.2      35.5      36.9      50.0      18.8      17.6      39.1
  459.  % Direct     14.7      17.9      16.9      12.1      22.6      27.7      12.4
  460.  % Select      5.2       4.2       3.5       3.2       4.3       5.0       3.6
  461.  
  462. JWW
  463.  
  464.  
  465. From      : g0k8ka
  466. To        : all
  467. Keywords  : SEU F6FBB
  468. Uploaded  : Fri May 24 10:32:05 1991
  469. __________________________
  470.  
  471. The "uncorrectable SEU" means that somewhere in a file, more than 2 bytes
  472. were corrupted in a single 256-byte block. If you download the file after
  473. this, you will always get a checksum error when extracting the header.
  474. On text files, this is not much of a problem, but on .zip or other binary
  475. files, it makes them useles.  Uncorrectable SEUs are very rare; out of the
  476. 1267 SEUs which have been corrected since the 9 April reload, only 7 have
  477. been uncorrectable. Files 1550, 176e, 1653 and 4 unidentified files were
  478. effected. We'll try to improve this by speeding up the wash rate.
  479.  
  480. You can keep track if this yourself by looking at the eltlog file with
  481. the program elogdisp. Look for SEVERE errors, as these are the ones which
  482. couldn't be corrected.
  483.  
  484. I'm glad that people are using the system to transfer big files, and would
  485. like to encourage experimentation (voice, fax, images ...).
  486.  
  487. JWW
  488.  
  489. From      : g0k8ka
  490. To        : all
  491. Title     : PB tx delay
  492. Uploaded  : Sat May 25 10:04:32 1991
  493. __________________________
  494.  
  495. WB9MJN indicates that when he starts PB, it doesn't go into
  496. full duplex mode and the TX delay doesn't get set. (The symptom
  497. of the TNC not being in full duplex mode is that it must wait for your
  498. DCD line to flicker before it will send your broadcast request packets.)
  499.  
  500. I think that this problem (which we had in the UoS control station as well)
  501. is caused by lack of appropriate delay between putting the TNC in KISS
  502. mode and sending the full-duplex and TX delay commands. If the TNC is
  503. still busy flashing the STA and CON lights then it misses the commands.
  504. A cure for this has been available in PB for some time:
  505.  
  506. restart_delay 60
  507.  
  508. in your PG.CFG file will cause PB to delay 3 seconds before and after
  509. putting the TNC into KISS mode. The txd and fulldup commands should now be
  510. accepted correctly.
  511.  
  512. You should see the commands be sent to the TNC as a brief flicker on STA after
  513. CON and STA have finished their blinking.
  514.  
  515. JWW
  516.  
  517. From      : g0k8ka
  518. To        : g3rwl
  519. Title     : PG/PB Suggestions
  520. Keywords  : PG PB
  521. Uploader  : G0K8KA
  522. Uploaded  : Wed Jun 05 14:52:47 1991
  523. __________________________
  524. Richard,
  525.  
  526. Thanks for the observations r.e. PG and PB. In order
  527.  
  528. 1) Auto detection of "OK" packets: Eventually, I'll put that in, but
  529. I suspect that it will generate a lot of automatic rubbish on the uplink.
  530. I'm also going to have a periodic beacon telling what stations' requests
  531. are still in the broadcast rotation being serviced.
  532.  
  533. 2) Message editor: If I do this, it will be a shell to DOS or shell to your
  534. favourite editor (like Procomm does). I don't want to write even a simple
  535. editor myself.
  536.  
  537. Of couse, there is no need to force a disconnect while viewing/composing
  538. mail, since the default state for PG is disconnected.
  539.  
  540. Combined PG/PB would indeed be desirable, but can only be done well if I
  541. use an AX.25 implementation running on the PC, with the TNC only acting
  542. in KISS mode. Any suggestions as to a source of full featured TSR or
  543. linkable "software TNC" will be accepted. The BPQ code isn't flexible enough
  544. for this particular task, since it thinks it's a 'node' with all the
  545. attendant peculiarities. I can't honestly see this task coming up the
  546. list until next year, though. Perhaps by then someone else will have
  547. done it. (In fact, PE1CHL has already done it for NET users.)
  548.  
  549. 3) MCON ON - Frightning. With TAPR TNC firmware there is no reliable way
  550. to separate connected-mode data to me from monitored data - certainly not
  551. in the face of a full binary link. This would only become possible when
  552. using a   KISS TNC and software AX.25 on the PC, as above.
  553.  
  554. 4) PgUp/PgDn implementation. I could have some overlap, but once you
  555. know that nothing is missed, this becomes a non problem, doesn't it?
  556.  
  557. 5) The spacecraft software includes selective directories, but no
  558. attempt has been made to impelement them in PG. I'll probably look at
  559. some useful new SELECTs this summer in conjunction with a BBS
  560. forwarding release of PG.
  561.  
  562. Frankly, since connected mode should only be used for uploading, you
  563. shouldn't worry about 'clogging the system'. It's
  564. all the people still using connected mode for downloading who should
  565. worry.
  566.  
  567. 6) More elegant program exit. Hmm. I exit through the standard
  568. Microsoft C exit function and program shutdown code. In fact, after I
  569. got your message, I checked that both PG and PB could be used in
  570. batch files. I had success here, and can't see what your difficulty
  571. is. Drop me one of your menu files and let me play around with it.
  572. (Nev thought your problem could have comething to do with FILES= in
  573. config.sys.)
  574.  
  575. 7) The file directory is in date order. The file date is set when the
  576. file is completely uploaded, or in the case of on-board files
  577. (ALxxxx, CPxxxx, WDxxxx, and ELTLOG), when the file is "posted" by
  578. the generating program. As far as I can tell, date order is the only
  579. useful order for the directory, since is assures that you will see
  580. files when they are really "new". Consider the eltlog - it would
  581. always be the lowest file in the directory if files were sorted by
  582. number. Or, worse, if I start uploading a file on Friday, but don't
  583. finish it, it clearly can't show up in your directory yet. Then I
  584. complete the file Monday, but it shows up in numerical order, e.g.
  585. you'll probably miss it because of the 40 files uploaded over the
  586. weekend. The "elegant", "truely sequential" order - e.g. file number
  587. order - is not really representative of reality. File numbers are
  588. just handles for the files.
  589.  
  590.  
  591. Thanks for the input, and I'm glad to see you active on the system. The
  592. UoSAT-2 bulletins are also appreciated.
  593.  
  594. JWW
  595.  
  596. From      : g0k8ka
  597. To        : all
  598. Title     : NO -1 & NO -2
  599. Uploader  : G0K8KA
  600. Uploaded  : Thu Jul 18 22:47:15 1991
  601. __________________________
  602. I'm sorry I forgot to tell you all before:
  603.  
  604. NO -2 <callsign> means file not found. File has been deleted.
  605. NO -1 <callsign> means broadcast queue full.
  606.  
  607. Most people have probably already figured it out, but I wanted to
  608. document it just in case.
  609.  
  610. JWW
  611.  
  612. From      : g0k8ka
  613. To        : wb7qkk
  614. Title     : ;) Means ...
  615. Keywords  : PG CON TNC
  616. Uploader  : G0K8KA
  617. Uploaded  : Tue Nov 12 12:37:27 1991
  618. __________________________
  619. Bill
  620. The message ;) indicates that your TNC is not informing your
  621. PC that you are connected to the satellite. This generally
  622. means that you don't have the connect line hooked between
  623. TNC and PC. It may also indicate that the TNC asynch
  624. port does not have the connect status on the DCD pin. This
  625. is pin 1 on the DB-9 connector.
  626.  
  627. What I can't understand is how you are able to work on
  628. UO-14. I suspect that you must use a different TNC and
  629. a different RS-232 cable.
  630.  
  631. Jeff
  632.  
  633.  
  634. From      : g0k8ka
  635. To        : all
  636. Title     : No evidence
  637. Uploader  : G0K8KA
  638. Uploaded  : Sun Nov 17 11:44:53 1991
  639. __________________________
  640. Please.
  641.  
  642. It's time for everyone to stop speculating about the UO-14
  643. uplink "problems" over Europe. There is no technical evidence to
  644. suggest that any station which uses the UO-14 BBS is responsible for
  645. the super strong signal on the uplink.
  646.  
  647. Those of you who listened at 1015 on Saturday morning will have heard
  648. exactly what was on the uplink, when I threw it into analogue repeater
  649. mode toward the end of the pass. I made out:
  650.  
  651.  (1) no FSK modulation on the signal
  652.  (2) generally no intelligence on the signal
  653.  (3) some tones which sounded like access tones for terrestrial repeaters
  654.  (4) at least one burst of full quieting FM voice in Spanish or Italian
  655.  
  656. Instead of trying to find and identify the interfering source by
  657. suspecting those who actually use the satellite to communicate,
  658. why not try to map out the extent of excessive signal strength on
  659. the RX1 RSI channel of UO-3's telemetry. Excessive means anything
  660. approaching or exceeding 4 volts.
  661.  
  662. ON THE BIG UPLOAD TOPIC
  663.  
  664. If we want to use UO-3 to send large files, then there are going to be
  665. some large uploads. The stations making these large uploads are going
  666. to attract attention, but we are playing a "zero sum game". If it takes
  667. N minutes of link time to uplink the message, those N minutes can't be
  668. used by other stations for other purposes.
  669.  
  670. I think that it is reasonable to ask for these uplinks to be broken
  671. every couple of minutes, but this is purely a personal point of view,
  672. and can't really be backed up by a technical argument.
  673.  
  674. My view of the satellite is that if you can get one directory in the
  675. morning and one in the evening then the system works. When the
  676. broadcast directory is in place, this will not be a problem. But we
  677. shouldn't waste too much time ringing our hands over the current
  678. situation; the system works - more than 50 messages a day are uploaded by
  679. 150 active stations.
  680.  
  681. JWW
  682.  
  683. P.S. - To those who have been accused: thanks for staying calm. If you
  684. get really angry, write a letter and send it in the post, or make a phone
  685. call. Let's try not to let UO-3 degenerate into what's worst about
  686. terrestrial packet.
  687. From      : db2os
  688. To        : g0k8ka,all
  689. Title     : New PB, some hints
  690. Keywords  : PB
  691. Uploader  : DB2OS
  692. Uploaded  : Sat Dec 21 18:39:38 1991
  693. __________________________
  694. PG 21/12/91 15:00utc
  695.  
  696. Hello Jeff and Users!
  697.  
  698. New PB works excellent!
  699.  
  700. some small bugs found:
  701.  
  702. 1) txdelay
  703. Initial value of 150ms in the .cfg file seems to be too long.
  704. txd 50 should sufficient on UO-14 with most transceivers
  705. (for UO-22 I need txd 70).
  706.  
  707. Users: Please keep the TXDELAY as short as possible.
  708.  
  709.  
  710. All in all, a very nice program and I now see more 'open' messages on
  711. the screen.. :-)  Let's start uploading many nice Christmas Greetings
  712. for Jeff and all at UoS!
  713.  
  714. 73s Peter DB2OS
  715. * MERRY CHRISTMAS and a happy NEW YEAR *
  716.  
  717. From      : wa2lqq
  718. To        : all
  719. Title     : Dir Problem Symptoms
  720. Keywords  : PB Shutdown Problem?
  721. Uploader  : WA2LQQ
  722. Uploaded  : Fri Dec 27 03:57:24 1991
  723. __________________________
  724.                                           0300UTC 27Dec91
  725.  
  726. Greetings from another one who has current problems with PB.
  727. As others have here noted, there are problems with losing
  728. the directory display.
  729.  
  730. Let me add a few symptoms to the pile so far amassed.
  731.  
  732. I am NOT implementing any Block file type via .CFG yet have experienced
  733. the same problem as others. So I think I would rule out file blocking
  734. as a cause.
  735.  
  736. Moreover, I let PB run for a couple of days without exiting to DOS and
  737. everything continued to work fine with PB. The directory filled and
  738. was maintained normally. THEN, however, the very first time I exited to
  739. DOS and then returned to PB, the directory was fouled up in the
  740. "usual" way, i.e., entries from the 25th on were missing.
  741.  
  742. My suspicion leans towards the PB shudown mechanism. Perhaps the PFHDIR.PFH
  743. file is not put to disk properly. Perhaps once the file gets too large
  744. (equating to about 25Dec from the start point) it can no longer
  745. be logged in the proper manner. Or more likely, perhaps once it reaches
  746. a certain size, it cannot be recalled properly because of the way it was
  747. recorded upon shutdown. (I recall someone said the directory actually was on
  748. disk; it just was not being recalled and displayed properly.
  749.  
  750. Again, my central thesis is that the problem is not associated with
  751. Blockftype, but rather in the PB shydown procedure. My evidence is
  752. in repeatable experiments performed here since the problem first
  753. manifested, i.e., if you leave PB running, it has no problems.
  754. But, if you exit from PB to read a logged message, you'll find the
  755. directory problem upon restarting PB.
  756.  
  757. So that's my input.
  758.  
  759. "Neeeeeeeext!"
  760.  
  761. 73 Rip
  762.  
  763.  
  764. From      : ja6ftl
  765. To        : All,PB
  766. Title     : Vanishing directory
  767. Keywords  : PB problem
  768. Uploader  : JA6FTL
  769. Uploaded  : Fri Dec 27 01:12:29 1991
  770. __________________________
  771. Peter notified that block type 12 disturb captureing directory bcst.
  772. But my experience this night was different.
  773. After directory trouble, I deleted the all related file and capture again
  774. from the first. This time my configuration was
  775.  
  776. blockftype 2
  777. blockftype 5
  778. blockftype 99
  779. blockftype 11
  780. blockftype 12
  781. ;
  782. There was no inconvenience and directory list was completed.
  783. After reading Peter's note, I edit PB.CFG and comented out "blocktype 12" line.
  784.  
  785. I re-start PB, resulted ... All directory dated 25 vanished never to reappear!
  786.  
  787. It seemed any block type itself is NOT trouble maker but renewing PB.CFG file
  788. is the cause of my trouble.
  789.  
  790. Take care about editing PB.CFG
  791.  
  792.  
  793. DIRECTORY BUG CURE !!!!!
  794. ~~~~~~~~~~~~~~~~~~~~~~~~
  795.  
  796. I wanted to pass my changes to PFH first to Rob PE1CHL, rather than upload
  797. a variant to confuse things, but the recent problems with PFHDIR.PFH
  798. "losing" new entries prompted me to upload a MSDOS version that can "fix" a
  799. damaged directory created by the new 911221 PB.EXE.  I also include a diff file
  800. showing where I have made changes to the PFH 1.2d base code.
  801. So, to recover whatever is possible from a damaged PFHDIR.PFH, issue
  802. this command:  pfh -cs pfhfir.pfh
  803.  
  804. The damaged directories seem to have a sequence of good headers, followed
  805. by a partial header that lacks the proper AA55 introduction.  PB seems to stop
  806. its header scan at this point while starting up, but pb can find newly-acquired
  807. dir entries.  When PB is exited, the new entries are written after the
  808. malformed entry, leading to their "loss" when PB is invoked again.
  809. I changed PFH to discard invalid header pieces so as to re-sync at the next
  810. valid header (having an AA55 introducer).  This seems to recover
  811. much of the lost data.  Also, I have seen no problems with compatibility
  812. with SLIST.DAT.  Perhaps I've been lucky?
  813.  
  814. One more point: PFH can display the directory (use the -d option).
  815. The grab/priority/auto/never flags are apparently stored in
  816. SLIST.DAT, which is not processed by pfh.
  817.  
  818. Do let me know if you find a problem with this fix method.  I suppose it
  819. is no worse that starting over!
  820.  
  821. 73 & season's greeting, de James N5KNX
  822.  
  823. From      : nk6k
  824. To        : all
  825. Title     : "not a jpeg" explained.
  826. Keywords  : jpg jpeg
  827. Uploader  : NK6K
  828. Uploaded  : Sat Jan 04 06:50:36 1992
  829. __________________________
  830. Not a JPEG file
  831.  
  832. If you don't use the -j option when you use gif2jpg, you can't view
  833. the resulting file with some versions(all?) of alchemy.
  834.  
  835. I've also had trouble displaying Macbinary built files with the 1.3 version
  836. of alchemy, the 1.4 version does better.
  837.  
  838. If you are using gif2jpg, use the -j option to make the most portable
  839. file.
  840.  
  841. Harold.
  842.  
  843.  
  844. From      : g0k8ka
  845. To        : all
  846. Title     : UO-14 Status (Thursday)
  847. Uploader  : G0K8KA
  848. Uploaded  : Thu Jan 16 09:26:10 1992
  849. __________________________
  850. UO-14 Status (Thursday 16 January)
  851.  
  852. The tests of UO-14 on the non-amateur frequencies are going well,
  853. and I expect that we will be able to restore full operation to the
  854. amateur frequencies on Friday A.M. UTC. There is even some sign
  855. that we are closing in on the underlying software bug.
  856.  
  857. Thank you all for your cooperation; I do understand that some
  858. automated stations will have transmitted "without human
  859. collaboration" and that's not a major problem.
  860.  
  861. Because of the shortage of memory on UO-14 and the relative
  862. glut of memory on UO-22, we may make some changes to satellite
  863. usage in the amateur service soon. Translation? "Check out your
  864. station's operation on UO-22 to prepare for changes."
  865.  
  866. JWW
  867.  
  868. From      : g0k8ka
  869. To        : all
  870. Title     : UO-14 News
  871. Keywords  : UO-14 PB FTL0
  872. Uploader  : G0K8KA
  873. Uploaded  : Fri Jan 24 10:59:31 1992
  874. __________________________
  875. ** Watch the Downlink **
  876.  
  877. The downlink of UO-14 is its "general beacon." Messages on the downlink
  878. indicate what state the satellite is in, and what operations you can
  879. expect to succeed at.
  880.  
  881. On Wednesday, I had to unload the FTL0 server to investigate the loss
  882. of 1.8 MBytes of RAMDISK space. I unloaded FTL0, loaded a program to
  883. peek the File Access Table (FAT) and Directory area of the RAMDISK, and
  884. downloaded the peek file. Then I used a ground program to analyse the
  885. FAT and Dir. I found the lost clusters, and on Thursday reloaded UO-14
  886. with a special file system to recover the clusters.
  887.  
  888. During this operation, there was no FTL0 server, and so PG would not work.
  889. This is easy to detect: there were no BBSTAT packets on the downlink. No
  890. BBSTAT = no FTL0 = no PG and no uploading.
  891.  
  892. ** Automatic File Delete Times **
  893. From Thursday, I have modified FTL0 to examine what you put in the
  894. EXPIRE_TIME field of an uploaded message. [Users of pfhadd.exe don't
  895. have a way to alter this yet, so can ignore this matter.]
  896.  
  897. If your EXPIRE_TIME is in less than four days from the completion of
  898. your upload, then it will be used instead of the system default.
  899.  
  900. If your EXPIRE_TIME is greater than four days from the completion of
  901. your upload, or EXPIRE_TIME is 0, then your message will become
  902. "deleteable" in 4 days.
  903.  
  904. Partial messages will be deleted 36 hours after they are created, if
  905. you do not complete the upload.
  906.  
  907. These measures should help relieve the congestion on UO-14. I encourage
  908. you to use a short EXPIRE_TIME if you know that the station you are
  909. communicating with can be trusted to download its mail in less than 4
  910. days. If everyone uses this feature sensibly, then I may bump the system
  911. default to 7 days so that keplerian elements and bulletins are kept
  912. for one week.
  913.  
  914.  
  915. From      : g0k8ka
  916. To        : w0sl
  917. Title     : Old answers
  918. Uploader  : G0K8KA
  919. Uploaded  : Wed Jan 29 20:03:03 1992
  920. __________________________
  921. Roy,
  922.  
  923. Just to answer a couple of outstanding queries:
  924.  
  925.    It is likely that you will get an error (e increment) when
  926.    you go to the directory view or do anything which could
  927.  
  928.    (A) occupy the CPU for more than (4000*8)/9600 seconds
  929.  
  930.    (B) turn off the interrupts for more than 8/9600 seconds
  931.  
  932. I wouldn't worry about it!
  933.  
  934. JWW
  935.  
  936. From      : g0k8ka
  937. To        : all
  938. Title     : Move over to UO-22
  939. Keywords  : UO-3 UO-22 NEWS
  940. Uploader  : G0K8KA
  941. Uploaded  : Tue Feb 04 00:21:00 1992
  942. __________________________
  943. *** Amateur Radio Operations Move from UoSAT-3 to UoSAT-OSCAR-22 ***
  944.  
  945. 3 February 1992
  946. University of Surrey
  947.  
  948. In late December, we introduced an enhanced broadcast server on
  949. UoSAT-3, which did a lot to reduce congestion on the satellite's
  950. single uplink; now we have another bottle-neck. Because UoSAT-3 has
  951. only 256 kBytes of program/data memory, we are using a RAMDISK which
  952. can only hold 400 messages at a time; with uplink contention reduced,
  953. gateways on line, and more than 150 stations regularly active, this
  954. 400 message limit is often exceeded. When the satellite is full, new
  955. messages cannot be uploaded, and older messages have short lifetimes
  956. (before being deleted automatically to make way for new messages).
  957.  
  958. The large population of amateur radio stations on UoSAT-3 is also
  959. somewhat limiting for the non-amateur stations which get only very
  960. small access windows (roughly 1:5 of the opportunity given to amateur
  961. stations). The brief bursts of transmission on the non-amateur
  962. downlink interrupt amateur activity and also make it difficult for
  963. automatic frequency control circuits to operate on the non-amateur
  964. downlink.
  965.  
  966. In addition to UoSAT-3 (OSCAR-14) the controllers at Surrey have
  967. UoSAT-5  (OSCAR-22) as a potential resource. SatelLife - the
  968. organisation which paid for most of UoSAT-5 - had planned to operate
  969. the satellite predominantly on non-amateur frequencies.  Operation of
  970. the CCD camera on the amateur downlink was to be a "secondary"
  971. activity of UoSAT-5.
  972.  
  973. After launch, this plan has run into two difficulties: The UoSAT-5 CCD
  974. camera has proven very successful, and amateur radio stations around
  975. the world are downloading the images of the Earth; images are taken
  976. several times per week, and each is more than 300 kbytes of data.
  977. Furthermore, UoSAT-5's high power amplifier which has produced
  978. excellent output on the amateur frequencies - does not work reliably
  979. on the non-amateur frequencies.
  980.  
  981. Taking into account the resources available to us and our obligations
  982. to SatelLife and other organisations, we have decided to take the
  983. following steps to optimise our use of UoSAT-3 and UoSAT-OSCAR-22:
  984.  
  985. 1) All non-amateur traffic, both SatelLife and VITA will be carried on
  986. UoSAT-3, which will cease to transmit on its amateur downlink.
  987.  
  988. 2) All amateur traffic will move to UoSAT-OSCAR-22, and UoSAT-OSCAR-22
  989. will operate as a dedicated amateur radio satellite transmitting
  990. constantly on its amateur downlink.
  991.  
  992. Of course, there is a price to pay for this transition: Most notably,
  993. the conflict between CCD users who want to download large CCD image
  994. files and "BBS" users who just want to get their mail. We are looking
  995. into on-board JPEG compression for the images, and this potential
  996. disadvantage will be balanced by the following advantages:
  997.  
  998. - 512kBytes of program memory permitting 800 message capacity
  999.  
  1000. - two amateur-radio uplinks : 145.900 and 145.975
  1001.  
  1002. - no downlink frequency switching (permanently on 435.120)
  1003.  
  1004.  
  1005. ** THE  BIG SWITCH **
  1006.  
  1007. The UO-22 file server is now enabled, and we recommend that all new
  1008. messages be uploaded to UO-22 and not to UoSAT-3. The UoSAT-3 FTL0
  1009. server will be disabled sometime on Wednesday, February 5, and
  1010. UoSAT-3's amateur downlink will be turned off.  I apologize for the
  1011. short notice, but there is engineering work on UO-3 which must be
  1012. done this week, and there hasn't been enought time for a more gradual
  1013. transition to be publicised.
  1014.  
  1015.  
  1016. Jeff Ward G0/K8KA
  1017. University of Surrey Spacecraft Engineering
  1018. Research Unit
  1019.